Very cool, and probably of much more general use than my virtual memory setup (although being able to malloc an 8MB block was kind of neat...). I heard the impact to performance was minimal in your tests which is even more amazing.

One thing I see you didn't pull in is the changes I did to make the memory accessible. When using the non32b exception handler, UMM can manage the memory as just another heap, allowing users to malloc() and new() with impunity. I think that would make it much more usable for general folks.

The interface could be the stack one I tried (worked well for me and let me hack libs to silently use internal/fast or external/slow), or @devyte was thinking more of a single flag (normal/iram/external) for simplicity.

Any thought from you on malloc interfaces?

Also, PlatformIO is not liking the .ld->.h conversions you've done. I can't quite grok what's wrong and have never been able to get a working general PIO install running on my system, but you might want to take a look.

@earlephilhower Thanks for the kind words.

One thing I see you didn't pull in is the changes I did to make the memory accessible. When using the non32b exception handler, UMM can manage the memory as just another heap, allowing users to malloc() and new() with impunity. I think that would make it much more usable for general folks.

Yes, that was in a different PR that I meant to go back and look at. I was hoping that I could adapt UMM to do that when I added the non32b; however, I think I see an issue in the ROMs _xtos_c_wrapper_handler for processing exceptions. It does a rsil 0 a little bit before calling the registered exception handler.

I also had trouble with the Hello Bear example when I fixed it up with an iRAM stack directly. My memory has faded on the specifics, I don't remember the kind of crash. I suppose it could be interrupt related. --- Just looked through your PR --- Not sure why I had trouble and you didn't with the Bear stuff. I'll have to try that again.

I am also thinking that UMM should revert back to internal DRAM, anytime it is called with interrupts disabled. That would result in all the iRAM allocations occurring in the foreground and maybe for exception processing disable IRQs at the start and leave it to the exit logic to restore PS.

Any thought from you on malloc interfaces?

Not sure. While simplicity is usually best, this is not looking very simple. DRAM, IRAM, FLASH, and external SRAM each have different performance properties and concerns. For now, I'll look at merging in your umm_malloc changes.

PlatformIO

Yea I didn't know what to do about that. I have an idea now that might work better w/o all the renaming to .h, I'll push it in a couple of days.

I also had trouble with the Hello Bear example when I fixed it up with an iRAM stack directly. My memory has faded on the specifics, I don't remember the kind of crash. I suppose it could be interrupt related. --- Just looked through your PR --- Not sure why I had trouble and you didn't with the Bear stuff. I'll have to try that again.

I was unable to get the SSL stack in external SRAM working, and I doubt that you'll be able to make it work in IRAM, either. There is no problem other than it's too slow and accessed on non-word boundaries, and accessed too intensely. I get a WDT w/external SRAM for the BSSL stack, and I would bet that's what you're seeing too.

I actually moved the 17KB SSL buffer (i.e. the per-connection info) to SRAM and that ran fine and any perf. difference was undetectable. I also moved the String() allocator to it, too, and also had no issue in anything I tested.

It's probably a matter of adding more optimistic_yield()s in the library, but I didn't look into it.

Re eb9882e. I don't see any errors showing up in the CI... if that's the reason for confusion about PIO issues, here some locally rolled back to 91fc391. Paths are cleaned up for readability:

cores/esp8266/exc-c-wrapper-handler.S: Assembler messages:
cores/esp8266/exc-c-wrapper-handler.S:99: Error: literal pool location required for text-section-literals; specify with .literal_position
cores/esp8266/exc-c-wrapper-handler.S:123: Error: literal pool location required for text-section-literals; specify with .literal_position
cores/esp8266/exc-c-wrapper-handler.S:99: Error: literal pool location required for text-section-literals; specify with .literal_position

@mcspr Thankyou! That was my problem.

@devyte

#7060 (comment)

  uint32_t v;
}  mmu_cre_status_t;

extern mmu_cre_status_t mmu_status;

Does this still need to be cleaned up?

That has been removed.

Congratulations @mhightower83, this is an awesome feature!

@devyte Thanks! It looks like that little POC for 16K/32K cache selection grew a little bit.

I want to thank @earlephilhower for his work on a virtual memory PR which I leverage to get started with the exception handler and 1st Heap selection API.

@devyte Thanks! It looks like that little POC for 16K/32K cache selection grew a little bit.

I want to thank @earlephilhower for his work on a virtual memory PR which I leverage to get started with the exception handler and 1st Heap selection API.

Thank you for this amazing option. It really comes in handy specially when using SSL, helping the ESP8266 instead of replacing with ESP32.

As a sidenote for newcomers when you use the tool, the extra HEAP won't show with the usual freeHeap function, but its there working and having extra heap.

@efitrillo That is good to hear.

The well-established Heap APIs, like freeHeap, work with the current Heap selected.
Do something like this to see the free IRAM Heap:

#include <umm_malloc/umm_heap_select.h>

#ifdef UMM_HEAP_IRAM
  {
    // Note, the current heap does not change if the IRAM Heap was not in the 
    // build option. In that case, ESP.getFreeHeap() will report free DRAM space.
    HeapSelectIram ephemeral;  
    Serial.printf("IRAM free: %6d\r\n", ESP.getFreeHeap());
  }
#else 
  Serial.printf("IRAM free: 0\r\n");
#endif